Fixes #29

This adds support for clickable URLs. This initial PR focuses on minimal URL support. There are obvious features which are not yet supported: OSC 8, links requiring keyboard modifiers, additional link actions (explained later), fully configurable links, etc.

This PR only adds support for URLs that match the default regular expression used by Alacritty, which matches various hyperlink URLs and opens them in the default system application. However, the implementation is built to support generic regex => action configurations, known as "links." These "links" are not yet configurable in the configuration file, but the base structure is there and everything is built on them.

The links system allows a user to configure (1) a regular expression to match (2) an action to execute (i.e. "system open") and (3) conditions to make the link active (i.e. hover). A default link is configured for typical network URLs to open with the system on hover.

Demo

Terminal Interaction

The primary interaction I could think of was with mouse reporting. If mouse reporting is active, links also can't be activated. If you hold "shift" (to escape mouse reporting capture), then links can be activated even with mouse reporting enabled. The "shift" behavior isn't new to this PR, that's been configurable with mouse-shift-capture for some time.

Otherwise, links work on both the primary and alternate screen.

Implementation

The implementation uses the Oniguruma regex engine under the hood. We run the regular expression matching twice (once in the GUI thread, once in the renderer thread) because they may have a different view of the viewport state.

The GUI thread checks for link matching whenever the cursor moves and changes viewport cells (i.e. not every pixel, but every cell). This latter detail helps limit the CPU spike when moving the cursor around. In general, the cursor isn't moving much over the terminal window so I don't think this will matter much.

The renderer thread checks for link matching whenever cells are updated, but only evaluates links against the current viewport and only if their highlight conditions are met (hover state, etc.). For the default URL link, this has a minimal impact but in the future when links are configurable, it's probably possible to configure a pathological case here.

Future Work:

• OSC 8
• Configurable links (this just requires writing the config parser part, the internals are already hooked up)
• Additional actions in addition to "open" (i.e. the ability to exec using regex captures)
• Configurable active link styling (today it just underlines)
• A mode where links can be navigated purely using the keyboard